1. Field of the Invention
The present invention relates to the restriction of programs that a user can run on a computer and, more particularly, to a thorough method for restricting unauthorized operations by a user on a single workstation computer or by a user on a session in a multi-user environment, such as Microsoft Windows 2000 Terminal Services.
2. Description of the Background
A prominent problem with computers and networks today is lax security. Viruses are rampant. Typically, a user is emailed a script program that is really a virus (like the “Love Bug” virus) and unknowingly runs the program associated with the script. Obviously, this can cause a wide range of problems. Also, when a computer system is “locked down”, hackers will often target the computer system to do nothing more than “break in”. Unfortunately, existing methods tend to trade-off the level of security with demand on system resources. There is no high performance, completely secure method available today to resolve this problem. To understand the problem, a brief overview of the Windows architecture is helpful.
FIG. 1 shows the Microsoft Windows 2000 architecture and illustrates the difference between user mode and kernal (or system) mode.
User mode is the least-privileged mode that Windows 2000 supports; it has no direct access to hardware and only restricted access to memory. For example, when software applications execute in user mode, they do so in a defined space with well-defined restrictions. They don't have direct access to hardware devices, and they can't touch parts of memory that are not specifically assigned to them.
On the other hand, system mode is a privileged mode. Those parts of Windows 2000 that execute in system mode, such as device drivers, have direct access to all hardware and memory. Other operating systems, including Windows NT, 3.1 and UNIX, also use analogous privileged and non-privileged modes. The services invoked in system mode are known as native advanced programming interface (“API”). The API is made up of about 250 functions that the operating system can access through software-exception system calls. A software-exception system call is a hardware-assisted way to change execution modes from user mode to system mode; it gives control over the data that passes between the two modes. Native API requests are executed by functions in system mode, known as system services.
As seen in FIG. 1, the Executive components include the I/O Manager, Object Manager, Security Reference Monitor, Process Manager, Local Procedure Call Facility, and Virtual Memory Manager. Each Executive component has a specific operating system responsibility. Device drivers are dynamically added components that work closely with the I/O Manager to connect to specific hardware devices, such as disks and input devices. The Executive components use basic hardware functionality implemented in the System. Client-side DLLs carry out tasks on behalf of their servers, but they execute as part of a client process. Given the foregoing overview, security will now be addressed.
In the Windows 2000 environment, there are two well known ways of controlling what programs (processes) specified users are allowed to run, and both have inherent flaws. One common way of marshaling processes is to use a technology known as a “filter driver”. A filter driver is built to work in conjunction with the I/O Manager, intercepting all I/O within the disk system. The filter driver marshals those processes that are allowed to pass through and halts any processes that are unauthorized. Filter drivers run in system mode and they slow down the computer system significantly by monitoring all I/O with the particular subsystem. Moreover, filter drivers are processor intensive and are prone to single point of failure as well as problems with data loss.
Another means for marshaling applications (processes) is to “disallow” unauthorized programs. For example, U.S. Pat. No. 5,802,397 (IBM) shows a system for protection from unintended I/O access. An I/O protection array or list is used containing one-bit I/O keys. Each one-bit I/O key is used to disallow I/O accesses into an associated storage block. This method is not very practical. Only specified accesses or applications can be restricted. A “hacker” can write their own program to break a system, and it would not exist in the disallowed list of programs (processes), thus being allowed to be run by the hacker.
It would be greatly advantageous to overcome the problems associated with the two above-described methods with a user mode thorough operation restriction approach (ThOR), whereby a user can only run what an administrator has explicitly allowed the user to run, and all other processes will be terminated. By running in user mode, only the processes created by users would need to be validated as opposed to processor-intensive validation of all file I/O. This would decrease the processing requirements for marshaling user processes. Data loss due to program failure would be eliminated as system I/O is not interfered with, and any catastrophic failures would be constrained to a single user. This is an important feature when running a multi-user operating system like Windows 2000 Terminal Services.